Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-101.txt

Text File | 1994-12-08 | 46.2 KB | 1,178 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 31 May 92       Volume 1 : Issue 101

Today's Topics:

    WANTED: Good/Comprehensive Mac Programming Book
    Format of ICON resource
    Numerical Programming in Think C
    Hey! I wrote a book!
    Introduction To Video Colour Spaces (was Re: YUV format)


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Robert P Kuehne)
Subject: WANTED: Good/Comprehensive Mac Programming Book
Organization: Iowa State University, Ames IA
Date: Tue, 28 Apr 1992 20:34:45 GMT


    Sorry if this is an FAQ, but...

    I am looking for a good book to get started on programming Mac
software.   Preferrably a book with a C emphasis.  Note:  I know C, etc,
but want a book that will give all the goodies on the Toolbox, IO,
etc...  I looked at Waldenbooks, but nothing there caught my eye.
If you can help, drop me a note or post!
Thanks.

Bob
- --
 ---- _ o ---------------------------------------------------------------------
|   _ \<,_        "Oh, it's _you_, Bob!"             Robert P. Kuehne |
|  (_)/ (_)           - That Commmercial             [e-mail]  |
 -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Jeff Jungblut)
Date: 29 Apr 92 23:17:14 GMT
Organization: Crash TimeSharing, El Cajon, CA

Try "Using the Macintosh Toolbox with C", second edition, by
Huxham/Burnard/Takatsuka, published by Sybex, ISBN 0-89588-572-7.
$29.95 at B. Dalton/Software Etc.

The emphasis is on making Toolbox calls using Think C.  I got halfway through
the book in one weekend and learned enough to write a simple space-invaders
game.

---------------------------

From: [e-mail] (Zachary 'Lego' Kessin)
Subject: Format of ICON resource
Organization: Brandeis University
Date: Wed, 29 Apr 1992 01:39:52 GMT

I want to know how the bits are arranged in the ICON resource. Are
they in 2 collums of 16 bits each or are they in one collum of 32
bits?
ie is it:
0   int   int
1   int   int
...
31  int   int

or
0    LongInt
1    LongInt
...
31   LongInt

thanks an advance!

- --Zach
   Zachary Kessin
 [e-mail]  / real.world: I don't think the    |
 [phone]                 /   news server gets that group!    |


+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 29 Apr 92 18:21:25 GMT
Organization: Kalamazoo College

[e-mail] (Zachary 'Lego' Kessin) writes:
>
>I want to know how the bits are arranged in the ICON resource. Are
>they in 2 collums of 16 bits each or are they in one collum of 32
>bits?
>
>is it:
>
>0   int   int
>...
>31  int   int
>
>or
>
>0    LongInt
>...
>31   LongInt

Yes.

It's either one.  It could be "char char char char" or
"nybble nybble nybble nybble nybble nybble nybble nybble"
or whatever you want.  It's a bit pattern.  However you
choose to represent it, the first 32 bits will comprise
the first line of the icon, the next 32 bits the second
line, and so on.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "Son, I am able," she said, "though you scare me." "Watch," said I,
 "beloved," I said, "watch me scare you though." Said she, "able am I, son."

---------------------------

From: [e-mail] (Elliotte Rusty Harold)
Subject: Numerical Programming in Think C
Date: 29 Apr 92 15:26:18 GMT
Organization: New Jersey Institute of Technology

>
> Another big problem with malloc for numerical programming is that
> many C compilers (including THINKC) won't malloc > 32K bytes of
> space (that's 4K doubles - which is not enough for numerical analysis).
> Typically, this fails by allocating 32K bytes and then allowing you
> to overwrite memory beyond the end of the 32K bytes (which causes
> bus errors if you're lucky and really strange behavior if your not).
>
>                                         -- Mike Webb

   Tell me about it! I'm working on a statistics program that starts off by
declaring several 32 by 32 by 9 arrays of floats. Think C stops the compile at
the first one because it's too big! I normally like to write and debug my
programs on the Mac and then move them to the Sparc for actual running, but now
I'm having to do everything on the Sparc (EMACS, Yuck!) Are there any plans to
cure this problem in Think C in any future version? In my opinion this 32K
segment limit makes Think an inappropriate developmnet environment for any
serious numerical work. Does MPW have this same limitation?

Elliotte Rusty Harold        Department of Applied Mathematics
[e-mail]        New Jersey Institute of Technology
[e-mail]        Newark, NJ 07103

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 29 Apr 92 18:31:57 GMT
Organization: Kalamazoo College

[e-mail] (Elliotte Rusty Harold) writes:
>[Mike Webb writes:]
>>
>> Another big problem with malloc for numerical programming is that
>> many C compilers (including THINKC) won't malloc > 32K bytes of
>> space
>
>   Tell me about it! I'm working on a statistics program that starts off by
>declaring several 32 by 32 by 9 arrays of floats. Think C stops the compile at
>the first one because it's too big!
>...
>In my opinion this 32K
>segment limit makes Think an inappropriate developmnet environment for any
>serious numerical work.

It would, if it existed.  (Should this be in the FAQ?)

You have two choices for getting more than 32K of data at a time.  The
first is to turn on "Far DATA."  This requires ThC 5.  The second is to
dynamically allocate it.

Mike Webb is wrong;  you can easily allocate more than 32K of data with
malloc.  Look at the source if you don't believe me;  allocations larger
than a certain size (15K) simply get passed to _NewPtr, and _NewPtr can
get you many megabytes.

Mike's problem is that he's not using function prototypes.  malloc
accepts a parameter of type size_t, which is typedef'd as unsigned long.
Without that prototype, the code assumes it's passing an int, which has
nasty and not-entirely-defined results.  Turn "prototype checking" on.

Elliotte, I think you're confusing static with dynamic allocation.
Declaring an array at the global level in C is static allocation, and
doesn't involve malloc.  Turning on Far DATA will assist you here.
If you want to dynamically allocate it, simply declare the array as a
pointer (in your case, "float (*myArray)[32][32]") and assign the
results of a malloc() to it (in your case,
"myArray = malloc(sizeof(float [32][32][9]))").
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "Son, I am able," she said, "though you scare me." "Watch," said I,
 "beloved," I said, "watch me scare you though." Said she, "able am I, son."

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Date: 29 Apr 92 20:13:09 GMT
Organization: GCC Technologies

In article <[e-mail]> [e-mail] (Elliotte Rusty Harold) writes:
>
>   Tell me about it! I'm working on a statistics program that starts off by
>declaring several 32 by 32 by 9 arrays of floats. Think C stops the compile at
>the first one because it's too big! I normally like to write and debug my
>programs on the Mac and then move them to the Sparc for actual running, but now
>I'm having to do everything on the Sparc (EMACS, Yuck!) Are there any plans to
>cure this problem in Think C in any future version? In my opinion this 32K
>segment limit makes Think an inappropriate developmnet environment for any
>serious numerical work. Does MPW have this same limitation?
>
    THINK C 5.0, which has been out for nearly a year, supports "far"
models for both code and data.

R.

- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer, Quickdraw Group
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail] (David Fry)
Date: 29 Apr 92 23:37:14 GMT
Organization: Harvard Math Department

In article <[e-mail]> [e-mail] (Elliotte Rusty Harold) writes:
>>
>> Another big problem with malloc for numerical programming is that
>> many C compilers (including THINKC) won't malloc > 32K bytes of
>> space (that's 4K doubles - which is not enough for numerical analysis).
>> Typically, this fails by allocating 32K bytes and then allowing you
>> to overwrite memory beyond the end of the 32K bytes (which causes
>> bus errors if you're lucky and really strange behavior if your not).
>>
>>                                         -- Mike Webb

Why is this continually propagated in this newsgroup?  malloc lets you
allocate more than 32K perfectly fine, provided you use it correctly.
Be sure to include <stdlib.h> and/or cast the size parameter for
malloc to (long).

>   Tell me about it! I'm working on a statistics program that starts off by
>declaring several 32 by 32 by 9 arrays of floats. Think C stops the compile at
>the first one because it's too big! I normally like to write and debug my
>programs on the Mac and then move them to the Sparc for actual running, but now
>I'm having to do everything on the Sparc (EMACS, Yuck!) Are there any plans to
>cure this problem in Think C in any future version? In my opinion this 32K
>segment limit makes Think an inappropriate developmnet environment for any
>serious numerical work.

This is a small problem, but using dynamic arrays allocated with
malloc does away with it.  I've done "serious" numerical work on the
Mac for years with no problem.  My programs run unaltered on the Mac
(in THINK C) and on other workstations.


David Fry                               [e-mail]
Department of Mathematics               [e-mail]
Harvard University                      ...!harvard!huma1!fry
Cambridge, MA  02138

+++++++++++++++++++++++++++

From: [e-mail] (David Fry)
Date: 30 Apr 92 02:34:33 GMT
Organization: Harvard Math Department

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>[e-mail] (Elliotte Rusty Harold) writes:
>>[Mike Webb writes:]
>>>
>>> Another big problem with malloc for numerical programming is that
>>> many C compilers (including THINKC) won't malloc > 32K bytes of
>>> space
>>
>>   Tell me about it! I'm working on a statistics program that starts off by
>>declaring several 32 by 32 by 9 arrays of floats. Think C stops the compile at
>>the first one because it's too big!
>>...
>>In my opinion this 32K
>>segment limit makes Think an inappropriate developmnet environment for any
>>serious numerical work.
>
>It would, if it existed.  (Should this be in the FAQ?)
>
>You have two choices for getting more than 32K of data at a time.  The
>first is to turn on "Far DATA."  This requires ThC 5.

I don't think this is right. The manual says that with Far Data,
you're still limited to 32K of global data per source file.  In
particular, you can't allocate an array more than 32K in size.  What
it does allow you to do, is have, say, 10 *.c files, each with a 20K
array.

David Fry                               [e-mail]
Department of Mathematics               [e-mail]
Harvard University                      ...!harvard!huma1!fry
Cambridge, MA  02138

+++++++++++++++++++++++++++

From: [e-mail] (Alen Shapiro)
Date: 30 Apr 92 03:59:04 GMT
Organization: Crash TimeSharing, El Cajon, CA

In <[e-mail]> [e-mail] (Elliotte Rusty Harold) writes:

>>
>> Another big problem with malloc for numerical programming is that
>> many C compilers (including THINKC) won't malloc > 32K bytes of
>> space (that's 4K doubles - which is not enough for numerical analysis).
>> Typically, this fails by allocating 32K bytes and then allowing you
>> to overwrite memory beyond the end of the 32K bytes (which causes
>> bus errors if you're lucky and really strange behavior if your not).
>>
>>                                         -- Mike Webb

>   Tell me about it! I'm working on a statistics program that starts off by
>declaring several 32 by 32 by 9 arrays of floats. Think C stops the compile at
>the first one because it's too big! I normally like to write and debug my
>programs on the Mac and then move them to the Sparc for actual running, but now
>I'm having to do everything on the Sparc (EMACS, Yuck!) Are there any plans to
>cure this problem in Think C in any future version? In my opinion this 32K
>segment limit makes Think an inappropriate developmnet environment for any
>serious numerical work. Does MPW have this same limitation?

Code is supplied below, tested under THINK C 5.0.2. I've used similar
array methods on SPARC and PC (yuch!!!).

The code allocates a 3D array on the heap (method does scale and
seems to be portable). Also you get to use [][][] style addressing. I threw
in the "f4" array just to see if it would allocate, it does. I did not
check to see if I could run off the end of memory...as it stands "f4"
cannot use [][][] addressing cos the compiler does not know the
x and y dimensions to build an access function. I know there is a caste
that will condition the access but I've not tried that yet.

So, as things stand, this code should use a bit more memory than the
flat access space that the compiler would generate, and is possibly
slightly more efficient at run-time. Please (if you have time) try it out
and let me know if it hits the spot (or not as the case may be).

- --alen
[e-mail]

- ------Cut here----8<-----8=-----8<-----
#include <stdio.h>
#include <stdlib.h>

void *
ccalloc(elems, sz)
    size_t elems, sz; {
    void *mptr = calloc(elems, sz);

    if(mptr == (void *)NULL) {
        fprintf(stderr, "calloc failed to allocate %ld of %ld\n", elems, sz);
        exit(1);
    }
    return(mptr);
}

void ***
three_d_array(x, y, z, el_size)
    size_t el_size; {
    int i, j;
    void ***arr = (void ***)ccalloc((size_t)x, sizeof(void **));

    for(i=0 ; i < x ; i++) {
        arr[i] = (void **)ccalloc((size_t)y, sizeof(void *));
        for(j=0 ; j < y ; j++)
            arr[i][j] = (void *)ccalloc((size_t)z, el_size);
    }
    return(arr);
}

#define X    32
#define Y    32
#define Z    9
main() {
    double ***f1;
    float ***f2;
    int x, y, z;
    float ***f4 = (float ***)ccalloc((size_t)X*(size_t)Y*(size_t)Z, sizeof(float));

    f1 = (double ***)three_d_array(X, Y, Z, sizeof(double));
    /* another (unused) for good measure!!) */
    f2 = (float ***)three_d_array(X, Y, Z, sizeof(float));

    /* check if each element is addressable...I used double to strain
     * the system a bit more
     */
    fprintf(stdout, "sizeof(float:double) = %ld:%ld\n", sizeof(float), sizeof(double));
    for(x=0 ; x < X ; x++)
        for(y=0 ; y < Y ; y++)
            for(z=0 ; z < Z ; z++)
                f1[x][y][z] = (double)x * (double)y * (double)z;

    for(x=0 ; x < X ; x++) {
        for(y=0 ; y < Y ; y++) {
            for(z=0 ; z < Z ; z++) {
                fprintf(stdout, "%f ", f1[x][y][z]);
            }
            fprintf(stdout, "\n");
        }
        fprintf(stdout, "\n\n");
    }
}
- -------end

---------------------------

From: [e-mail] (Keith Rollin)
Subject: Hey! I wrote a book!
Date: 23 Apr 92 21:34:49 GMT
Organization: Taligent

Well, it should finally be out. "Macintosh Programming Secrets", Second Edition,
should be in the stores in the next few days.

For those not familiar with it, MPS was originally written by Scott Knaster back
in 1987. It covered many interesting and non-trivial aspects of programming the
Macintosh, and included a lot of fun background and "whys and wherefores." Well,
a lot has happened since 1987, and the book has been almost entirely rewritten
by Scott and myself. Many of the old chapters were removed, and many new
chapters were added. Another big difference is that the second edition has
complete working source code for you to copy and put into your own
applications/INITs/whatever. There's also a coupon in the back for getting the
disk of source code.

Check out the introduction: I put the members of Usenet in the list of people to
thank because of all the questions that are posted here that need answering!

If you're interested in the book, it's $29.95 from Addison-Wesley, ISBN
0-201-58134-5. I'll refund a dollar to the first person who finds the two bogus
entries in the index.

(For you yahoos in DTS, get Abrams to buy everyone a copy...)

- ---
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 24 Apr 92 15:36:44 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> ([e-mail]), you write:
> Check out the introduction: I put the members of Usenet in the list of people to
> thank because of all the questions that are posted here that need answering!
>
> If you're interested in the book, it's $29.95 from Addison-Wesley, ISBN
> 0-201-58134-5. I'll refund a dollar to the first person who finds the two bogus
> entries in the index.

And, Keith, how much are you going to pay us for putting an obnoxious
commercial message in our face!! Play by the rules my friend!

tim.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Russell S. Finn)
Organization: MIT Laboratory for Computer Science
Date: Fri, 24 Apr 1992 22:28:22 GMT

In article <[e-mail]>, [e-mail] (Tim Endres) writes:
|> In article <[e-mail]> ([e-mail]), you write:
|> > Check out the introduction: I put the members of Usenet in the
|> > list of people to thank because of all the questions that are
|> > posted here that need answering!
|> >
|> > If you're interested in the book, it's $29.95 from
|> > Addison-Wesley, ISBN 0-201-58134-5. I'll refund a dollar to the
|> > first person who finds the two bogus entries in the index.
|>
|> And, Keith, how much are you going to pay us for putting an obnoxious
|> commercial message in our face!! Play by the rules my friend!

Sorry, but I think Keith *is* playing by the rules here.  There's a
difference between announcing availability of an item and actually
soliciting purchases, and to my understanding the former is permitted
while the latter is not.  I've seen plenty of examples of the former
in a variety of newsgroups.

It's not as if Keith said, "It's $29.95; make the check out to Keith
Rollin, and send it to this address; coupons for a free case of
Mountain Dew go to the first 5,000 orders, so hurry..."  I think we'd
all agree that would go beyond the pale.

I could go try to look up chapter and verse in the Gospel according to
St. Gene, as posted monthly in news.announce.newusers, but I'm not up
to it right now.

- -- Russell S. Finn
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Bill Leue)
Date: 27 Apr 92 13:12:35 GMT
Organization: General Electric Research & Development

Actually, I'm rather glad that Keith posted the notice of his new book.
There's not so much good documentation on Mac programming that we couldn't use
another one.  Come on people, lighten up!

- -Bill Leue
[e-mail]

P.S. - Keith, I hope this one is better proofread than the last book I bought
in the "Inside Out" series.  I can't remember the exact title -- something
like "Advanced C Programming on the Mac" (?)  Anyway, there were several major
howlers in the first chapter.  An example (repeated several times):
"if (a = b) {...} "  Yikes!  Scott had better hire better proofreaders than
this if he wants to preserve his good reputation!

+++++++++++++++++++++++++++

From: [e-mail] (Terry Thiel)
Date: 27 Apr 92 14:38:56 GMT
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL

[e-mail] (Bill Leue) writes:
>Actually, I'm rather glad that Keith posted the notice of his new book.
>There's not so much good documentation on Mac programming that we couldn't use
>another one.  Come on people, lighten up!
I agree.  I am very much against commercial ads in newsgroups but if its an
individual posting and especially the author it is very valuable information.
Its nice to know we can get ahold of the author if we want to also.
- -Terry

+++++++++++++++++++++++++++

From: [e-mail] (Dan Richard)
Date: 27 Apr 92 15:38:23 GMT
Organization: Macintosh Instructor

In article <[e-mail]>, [e-mail] (Terry Thiel) writes:
>
> [e-mail] (Bill Leue) writes:
> >Actually, I'm rather glad that Keith posted the notice of his new book.
> >There's not so much good documentation on Mac programming that we couldn't use
> >another one.  Come on people, lighten up!
> I agree.  I am very much against commercial ads in newsgroups but if its an
> individual posting and especially the author it is very valuable information.
> Its nice to know we can get ahold of the author if we want to also.
> -Terry
>
>
I second.
What is the name of the book?
Would the AUTHOR please post the table contents and brief summary/intro
as to its audience.

I would like to know about a book befor I buy it. I am always
looking for a better to learn from and to teach with.

Dan C. Richard
Macintosh Instructor

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 27 Apr 92 20:17:13 GMT
Organization: Taligent

In article <[e-mail]>,
[e-mail] (Dan Richard) writes:
>
> In article <[e-mail]>, [e-mail] (Terry
Thiel) writes:
> >
> > [e-mail] (Bill Leue) writes:
> > >Actually, I'm rather glad that Keith posted the notice of his new book.
> > >There's not so much good documentation on Mac programming that we couldn't
use
> > >another one.  Come on people, lighten up!
> >
> > I agree.  I am very much against commercial ads in newsgroups but if its an
> > individual posting and especially the author it is very valuable
information.
> > Its nice to know we can get ahold of the author if we want to also.
>
> I second.
> What is the name of the book?
> Would the AUTHOR please post the table contents and brief summary/intro
> as to its audience.
>
> I would like to know about a book befor I buy it. I am always
> looking for a better to learn from and to teach with.
>

Well, I hope this doesn't tick off Tim Endres and all who feel like him, but
here goes:

The book is called "Macintosh Programming Secrets, Second Edition." The first
edition of the book was originally published in 1987. For 1992, we've totally
rewritten the chapters and added tons of sample code. It's from Addison-Wesley,
ISBN 0-201-58134-5, 536 pages (did you know that "ISBN" really _does_ stand for
International Standard Book Number?).

Chapters 1 and 2 are pretty much the same as Chapters 1 and 2 of the first
edition. It talks about Macintosh history, philosophy, and programming
techniques. It's been revised to take into account the current state of Mac
technology, including multi-tasking, Color QuickDraw, System 7.0 and 32-bit
addressing.

The intermission that separates the philosophical discussions from the technical
discussions has been changed. Originally, there was a cartoon that explained
what happens during event processing in a Mac program. We've replaced that with
the text from a couple of Apple's greatest About boxes. First, there's the About
box from MultiFinder 1.0 with all the good parts put back in (the version
actually released to the public had the good parts bleeped out). Second, there's
the System 7.0a9 credits from the Circus Parade.

Chapter 3 presents a skeleton Macintosh application. The point here is not to
teach a beginner how to program the Mac, but to present the program that was the
basis for all the other programs in the book. You may want to check out the
sample application for things that all applications should do (like handle
disk-inserted events).

Chapter 4 is on Dialogs, and is loosely based on the original Dialog chapter of
the first edition. We present three things: a modal dialog that deals with
Cmd-key equivalents for dialog items, a movable modal dialog, and a dialog that
displays a progress indicator.

Chapter 5 is about QuickDraw. Much of the first part of the chapter is a
discussion on GrafPorts and CGrafPorts, updated from the first edition of the
book. The second half of the chapter develops an idea presented in the first
edition, where an offscreen buffer is used to save the contents of background
windows while a dialog is popped to the foreground, and later used to update
those windows when the dialog is closed.

Chapter 6 touches on mouse tracking. We show how to sketch out a selection, draw
the "marching ants," and drag around the selected graphics. Also included is a
snippet of code that reads in MacPaint pictures.

Chapter 7, on window management, shows how to implement a Windows menu that
contains the titles of all open windows. It also presents window tiling and
stacking algorithms that work across multiple monitors. As windows are
manipulated (opened, closed, changed), we perform zooming animation like the
Finder.

Chapter 8 shows how to use Standard File to select a file and a destination
directory, and then copies the selected file to that directory. No fancy stuff,
but enough people seem to have problems with the File Manager that showing such
basic operations seemed warranted.

Chapter 9 is all about standalone code. We show three kinds. To get your feet
wet, we show an INIT that simply beeps. We then develop it into an INIT that
patches a trap and stays resident in the system heap (this INIT is the most
useful INIT I've ever written! It allows me to emulate with a Cmd-key the action
of clicking on a window's zoom box. I know QuickKeys users aren't impressed, but
hey, I don't have QuickKeys). Next, we show how to write a WDEF for the windoid
that Apple made famous in HyperCard but never actually added to the system.
Finally, we present a custom LDEF that draws icons and which grays out
individual items. This last sample also shows how to insert a List Manager list
into a modal dialog.

Chapter 10 is a pot-pourri of samples that weren't large enough to warrant their
own chapters. Included are: How to Check for Cmd-Period, How to Spin a Cursor,
How to Hide the Menubar, and How to Ask for a Password Without Showing the User
What's Typed.


In the interest of the philosphy of Usenet, I should point out that many of the
techniques demonstrated in the book can also be found free from other sources.
Two major sources are the Usenet Macintosh Programmer's Guide (UMPG), and
Apple's Macintosh Technical Notes and Sample Code. For instance, UMPG contains
code that shows how to hide the menu bar, Mac Technote #263 shows how to
identify a Cmd-Period key-down event, and a recent addition to DTS's snippets
collection shows how to implement a password entry dialog.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 27 Apr 92 19:37:14 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Bill Leue)
writes:
> P.S. - Keith, I hope this one is better proofread than the last book I bought
> in the "Inside Out" series.  I can't remember the exact title -- something
> like "Advanced C Programming on the Mac" (?)  Anyway, there were several major
> howlers in the first chapter.  An example (repeated several times):
> "if (a = b) {...} "  Yikes!  Scott had better hire better proofreaders than
> this if he wants to preserve his good reputation!

I think that unsightly blemishes will always be a part of publishing. And I've
already found every single one in M.P.S., 2nd Ed (right...). For instance, in a
certain range of pages, "WindowPtr theWindow;" gets merged into
"WindowPtrtheWindow;". And in one place in the included source code, a character
of a variable name was dropped, creating a syntax error that's not in the
original source code. Scott says we should be able to get these fixed for the
second printing, so if anyone wants to contribute to the quality of the book,
send me mail.

> something
> like "Advanced C Programming on the Mac" (?)

If you can get me the exact name, I'll forward your comments on to Scott.

BTW: this is really weird, but even though Scott Knaster, the editor of the
Macintosh Inside Out series, is co-author of the book, the this book itself is
not part of the series. I don't know why...

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 30 Apr 92 15:27:15 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Keith Rollin) writes:
> > I second.
> > What is the name of the book?
> > Would the AUTHOR please post the table contents and brief summary/intro
> > as to its audience.
> >
> > I would like to know about a book befor I buy it. I am always
> > looking for a better to learn from and to teach with.
> >
>
> Well, I hope this doesn't tick off Tim Endres and all who feel like him, but
> here goes:

This SHIT belongs in a proper newsgroup: comp.newprod

MOVE IT THERE! It is not impolite to post a pointer to the article,
but I am getting REAL tired of this garbage taking up my bandwidth.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (K. Fischer)
Date: 30 Apr 92 15:52:38 GMT
Organization: LLNL

In article <[e-mail]>, [e-mail] (Tim Endres)
writes:
|>Path: lll-winken!ames!agate!spool.mu.edu!heifetz!tbomb!time
|>From: [e-mail] (Tim Endres)
|>Newsgroups: comp.sys.mac.programmer
|>Subject: Re: Hey! I wrote a book!
|>Message-ID: <[e-mail]>
|>Date: 30 Apr 92 15:27:15 GMT
|>Reply-To: [e-mail] (Tim Endres)
|>Distribution: usa
|>Organization: ICE Engineering, Inc.
|>Lines: 24
|>X-Mailer: uAccess - Macintosh Release: 1.7b4
|>
|>
|>In article <[e-mail]> (comp.sys.mac.programmer),
|>[e-mail] (Keith Rollin) writes:
|>> > I second.
|>> > What is the name of the book?
|>> > Would the AUTHOR please post the table contents and brief
|>summary/intro
|>> > as to its audience.
|>> >
|>> > I would like to know about a book befor I buy it. I am always
|>> > looking for a better to learn from and to teach with.
|>> >
|>>
|>> Well, I hope this doesn't tick off Tim Endres and all who feel like
|>him, but
|>> here goes:
|>
|>This SHIT belongs in a proper newsgroup: comp.newprod
|>
|>MOVE IT THERE! It is not impolite to post a pointer to the article,
|>but I am getting REAL tired of this garbage taking up my bandwidth.
|>
|>
|>tim endres - [e-mail]  -or-  uupsi!tbomb!time
|>ICE Engineering, Inc. - Phone [phone] - FAX [phone]
|>8840 Main Street, Whitmore Lake, MI  48189
|>USENET - a slow moving self parody... ph
|>

The only garbage I have seen here is YOUR posting tim -- get a grip
and get off your high horse.  The information was requested by
a reader and considering how many people post questions asking about
books, I feel this was a nice service of the AUTHOR to post it.  Maybe
you know everything and don't need books, but I'm a novice and
appreciate all  the advice I can get.  Perhaps you should go off and
form the comp.sys.mac.programmer.gods_only group for yourself
and those like you.

Kathleen
(who is usually a very nice and calm person except when provoked by
computer gods who think they know everything )
[e-mail]

DISCLAIMER:  I speak for myself only

---------------------------

From: [e-mail] (Charles A. Poynton)
Subject: Introduction To Video Colour Spaces (was Re: YUV format)
Date: 28 Apr 92 05:17:10 GMT
Organization: Sun Microsystems, Mt. View, Ca.

INTRODUCTION TO VIDEO COLOUR SPACES

Charles A. Poynton
Sun Microsystems Computer Corp.
(c) April 27, 1992

This note describes video luma (Y), and outlines six video-related colour
spaces:  (Y, B-Y, R-Y), YPbPr, YCbCr, Kodak PhotoYCC[tm], YUV and YIQ.
All of these spaces share the same luma (Y) signal; the other two signals
are "colour differences" that differ only in scaling (and in the case of
IQ, a rotation). The different scalings are appropriate for different
uses.

Often the symbol YUV is used loosely to represent generic
colour-difference space.  The scaling associated with YUV space is not
correct for component digital video, and YCbCr should almost always be
used instead.

To clear up some initial confusion, the symbol "Y" as used in video does
**NOT** have the same meaning as the symbol Y defined by the CIE and used
in colour science (such as in the CIE XYZ and CIE xyY colour spaces).
Both are associated with brightness, but in colour science, luminance --
denoted Y -- is proportional to linear-light intensity. Video originates
with linear light, but applies a power function with an exponent of about
0.45 to implement "gamma-correction".  I call the video Y symbol "luma" to
differentiate it from CIE "luminance".

Human vision treats brightness information very differently than colour
information, and this is fundamentally the reason that both colour science
and television identify a special channel to convey brightness-related
information.

Video uses U and V components to represent colour differences, but these
are essentially unrelated to colour science (u, v) or (u', v') or
(u*, v*). All of these pairs can loosely be described as representing
"chroma" but they are numerically and functionally different.  Video YUV
is neither based on nor superceded by any of the CIE colour-difference
spaces.


LUMA (Y)

Video originates with linear-light ("tristimulus") RGB primary components,
conventionally contained in the range 0 (black) to +1 (white).
>From the RGB triple, three gamma-corrected primary signals are computed;
each is essentially the 0.45-power of the corresponding tristimulus value,
similar to a square-root function.

In a practical system such as a television camera, however, in order to
minimize noise in the dark regions of the picture it is necessary to limit
the slope (gain) of the curve near black. It is now standard to limit gain
to 4.5 below a tristimulus value of +0.018, and to stretch the remainder of
the curve to place the Y-intercept at -0.099 in order to maintain function
and tangent continuity at the breakpoint:

  Rgamma = (1.099 * pow(R,0.45)) - 0.099

  Ggamma = (1.099 * pow(G,0.45)) - 0.099

  Bgamma = (1.099 * pow(B,0.45)) - 0.099

Luma is then computed as a weighted sum of the gamma-corrected primaries:

  Y  =  0.299*Rgamma + 0.587*Ggamma + 0.114*Bgamma

The three coefficients in this equation correspond to the sensitivity of
human vision to each of the RGB primaries standardized for video. For
example, the low value of the blue coefficient is a consequence of
saturated blue colours being perceived as having low brightness.

The luma coefficients are also a function of the white point (or
"chromaticity of reference white"). Computer users commonly have a white
point with a colour temperature in the range of 9300 K, which contains
twice as much blue as the daylight reference CIE D65 used in television.
This is reflected in pictures and monitors that look too blue.

Although television primaries have changed over the years since the
adoption of the NTSC standard in 1953, the coefficients of the luma
equation for 525 and 625 line video have remained unchanged. For
HDTV, the primaries are different and the luma coefficients have been
standardized with somewhat different values.


B-Y, R-Y

The human visual system has much less acuity for spatial variation of
colour than for brightness. Rather than conveying RGB, it is advantageous
to convey luma in one channel, and colour information that has had luma
"removed" in the two other channels. In an analog system, the two colour
channels can have less bandwidth, typically one-third that of luma. In a
digital system each of the two colour channels can have considerably
less data rate (or data capacity) than luma.

Green dominates the luma channel: about 59% of the luma signal comprises
green information. Therefore it is sensible -- and advantageous, for
signal-to-noise reasons -- to base the two colour channels on blue and
red.  The simplest way to "remove" luma from each of these is to subtract
it to form the "difference" between a primary colour and luma. Hence, the
basic video colour-difference pair is (B-Y), (R-Y) [pronounced "B
minus Y, R minus Y"].

The (B-Y) signal reaches its extreme values at blue (R=0, G=0, B=1;
Y=0.114; B-Y=+0.886) and at yellow (R=1, G=1, B=0; Y=0.886; B-Y=-0.886).
Similarly, the extrema of (R-Y), +-0.701, occur at red and cyan.  These
are inconvenient values for both digital and analog systems. The colour
spaces YPbPr, YCbCr, PhotoYCC and YUV are simply scaled versions of (Y,
B-Y, R-Y) that place the extrema of the colour difference channels at more
convenient values.


YPbPr

If three components are to be conveyed in three separate channels with
identical unity excursions, then the Pb and Pr colour difference
components are used:

  Pb = (0.5/0.886) * (Bgamma - Y)

  Pr = (0.5/0.701) * (Rgamma - Y)

These scale factors limit the excursion of EACH colour difference
component to -0.5 .. +0.5 with respect to unity Y excursion: 0.886 is just
unity less the luma coefficient of blue. In the analog domain Y is usually
0 mV (black) to 700 mV (white), and Pb and Pr are usually +- 350 mV.

YPbPr is part of the CCIR Rec. 709 HDTV standard, although different luma
coefficients are used, and it is denoted E'Pb and E'Pr with subscript
arrangement too complicated to be written here.

YPbPr is employed by component analog video equipment such as M-II and
BetaCam; Pb and Pr bandwidth is half that of luma.


YCbCr

The international standard CCIR Recommendation 601-1 specifies eight-bit
digital coding for component video, with black at luma code 16 and white
at luma code 235, and chroma in eight-bit two's complement form centred on
128 with a peak at code 224. This coding has a slightly smaller excursion
for luma than for chroma: luma has 219 "risers" compared to 224 for Cb and
Cr. The notation CbCr distinguishes this set from PbPr where the luma and
chroma excursions are identical.

For Rec. 601-1 coding in eight bits per component,

  Y_8b  =  16 + 219 * Y

  Cb_8b = 128 + 112 * (0.5/0.886) * (Bgamma - Y)

  Cr_8b = 128 + 112 * (0.5/0.701) * (Rgamma - Y)

Some computer applications place black at luma code 0 and white at luma
code 255. In this case, the scaling and offsets above can be changed
accordingly, although broadcast-quality video requires the accommodation
for headroom and footroom provided in the CCIR 601-1 equations.

CCIR Rec. 601-1 calls for two-to-one horizontal subsampling of Cb and Cr,
to achieve 2/3 the data rate of RGB with virtually no perceptible
penalty.  This is denoted 4:2:2. A few digital video systems have utilized
horizontal subsampling by a factor of four, denoted 4:1:1. JPEG and MPEG
normally subsample Cb and Cr two-to-one horizontally and also two-to-one
vertically, to get 1/2 the data rate of RGB. No standard nomenclature has
been adopted to describe vertical subsampling. To get good results using
subsampling you should not just drop and replicate pixels, but implement
proper decimation and interpolation filters.

YCbCr coding is employed by D-1 component digital video equipment.


Kodak PhotoYCC [tm]

Kodak's PhotoYCC colour space (for PhotoCD) is similar to YCbCr, except
that Y is coded with lots of headroom and no footroom, and the scaling of
Cb and Cr is different from that of Rec. 601-1 in order to accommodate a
wider colour gamut:

  Y_8bit = (255/1.402) * Y

  C1_8bit = 156 + 111.40 * (Bgamma - Y)

  C2_8bit = 137 + 135.64 * (Rgamma - Y)

The C1 and C2 components are subsequently subsampled by factors of two
horizontally and vertically, but that subsampling should be considered a
feature of the compression process and not of the colour space.


YUV

In composite NTSC, PAL or S-video systems, it is necessary to scale (B-Y)
and (R-Y) so that the composite NTSC or PAL signal -- luma plus modulated
chroma -- is contained within the range -1/3 to +4/3. These limits reflect
the capability of composite signal recording or transmission channel. The
scale factors are obtained by two simultaneous equations involving both
B-Y and R-Y, because the limits of the composite excursion are reached at
combinations of B-Y and R-Y that are intermediate to primary colours. The
scale factors are as follows:

  U = 0.493 * (B - Y)

  V = 0.877 * (R - Y)

U and V components are typically modulated into a "chroma" component:

  C = U*cos(t) + V*sin(t)

where t represents the ~3.58 MHz NTSC colour subcarrier. PAL coding is
similar, except that the V component switches Phase on Alternate Lines
(+-1), and the subcarrier is at a different frequency, about 4.43 MHz.

It is conventional for an NTSC luma signal in a composite environment
(NTSC or S-video) to have "7.5% setup":

  Y_setup = (3/40) + (37/40) * Y

A PAL signal has zero setup.

The two signals Y (or Y_setup) and C can be conveyed separately across an
S-video interface, or Y and C can be combined ("encoded") into composite
NTSC or PAL:

  NTSC = Y_setup + C

  PAL  = Y + C

U and V are only appropriate for composite transmission as 1-wire NTSC or
PAL, or 2-wire S-video. The UV scaling (or the IQ set, described below) is
incorrect when the signal is conveyed as three separate components.
Certain component video equipment has connectors labelled "YUV" that in
fact convey YPbPr signals.


YIQ

The U and V signals above must be carried with equal bandwidth, albeit
less than that of luma. However, the human visual system has less spatial
acuity for magenta-green transitions than it does for red-cyan. Thus, if
signals I and Q are formed from a 123 degree rotation of U and V
respectively [sic], the Q signal can be more severely filtered than I --
to about 600 kHz, compared to about 1.3 MHz -- without being perceptible
to a viewer at typical TV viewing distance.  YIQ is equivalent to YUV with
a 33 degree rotation -- AND AN AXIS FLIP -- in the UV plane.  The first
edition of W.K. Pratt "Digital Image Processing" -- and presumably other
authors that follow that bible -- has a matrix that erroneously omits the
axis flip; the second edition corrects the error.

Since an analog NTSC decoder has no way of knowing whether the encoder was
encoding YUV or YIQ -- it cannot detect whether the encoder was running at
0 degree or 33 degree phase -- in analog usage the terms YUV and YIQ are
often used somewhat interchangeably. YIQ was important in the early days
of NTSC but most broadcasting equipment now encodes equiband U and V.

The D-2 composite digital DVTR (and the associated interface standard)
conveys NTSC modulated on the YIQ axes in the 525-line version and PAL
modulated on the YUV axes in the 625-line version.


REFERENCES

"Television Engineering Handbook", second edition (1986) by K. Blair
Benson -- published by McGraw-Hill -- has an explanation of the principles
of colourimetry as applied to video systems. R.W.G. Hunt's book "Colour
Reproduction in Business, Science and Industry" is an excellent text on
many aspects of colour -- I recommend it highly -- but it has only a page
of rather dated information about NTSC and PAL composite video, and it
predates YCbCr.


C.

- -----
Charles A. Poynton                      Sun Microsystems Inc.
vox 415-336-7846                        2550 Garcia Avenue, MTV21-10
fax [phone]                        Mountain View, CA 94043
<[e-mail]>                       U.S.A.
"Canadian, eh."
- -----

+++++++++++++++++++++++++++

From: [e-mail] (Siri Hewa)
Date: 30 Apr 92 03:32:45 GMT
Organization: R&D, OTC Sydney, Australia

Well done for the Charles article, and I think it was too theoraticle, I will
try to put from the video broadcasters angle.

In 601 Digital or 4:2:2 standard, components are Y:U:V and EBU(european
broadcast union) clock rate is 13.5MHz. So Y is 13.5 MHZ and U and V is sampled
on 6.75Mhz separately. Thats why its called 422. I have designed this in 1987
when D1 was just to be released.(this was in ADAC st.convertor).
In Pal YUV and in NTSC its YIQ, now lots of people will argue and Iam not going
into details as if you do your theoratical calculation you will agree with me.
But now YUV is a universal name for Pal and Ntsc.(Only designers know the real
truth).
In Beta(dont get confused with the home format with this one) and MII component
format it is YUV format is used and only slight Luminance and chroma differs
between the two.
One of the cockups in graphic area is it was design by the normal hardware and
software engineers. If this field is tackled by broadcast engineers you will
not get lots of diff. standards and misleading technical information.
Broadcasters now going to 444 standard and I see no reason for this as existing
Pal and Ntsc is well supported with 422 and if HDTV become universal then we
may have think again about new digital format.

Siri Hewa.
OTC Research


---------------------------

End of C.S.M.P. Digest
**********************